PC Media 20/PC MEDIA CD20.iso/share/prog/aaformat/aaformat.txt

Text File | 1992-02-26 | 15.8 KB | 362 lines

Autodesk Animator files

     Following is a detailed description of the FLI file format,
as well as the formats for Autodesk Animator's other main file
types.

1 Flic Files (.FLI)

     The details of a FLI file are moderately complex, but the
idea behind it is simple: don't bother storing the parts of a
frame that are the same as the last frame.  Not only does this
save space, but it's very quick.  It's faster to leave a pixel
alone than to set it.

     A FLI file has a 128-byte header followed by a sequence of
frames. The first frame is compressed using a bytewise run-length
compression scheme.  Subsequent frames are stored as the
difference from the previous frame.  (Occasionally the first
frame and/or subsequent frames are uncompressed.)  There is one
extra frame at the end of a FLI which contains the difference
between the last frame and the first frame.

     The FLI header:

     byte size name      meaning
     offset

     0    4    size      Length of file, for programs that want
                         to read the FLI all at once if possible.
     4    2    magic     Set to hex AF11.  Please use another
                         value here if you change format (even to
                         a different resolution) so Autodesk
                         Animator won't crash trying to read it.
     6    2    frames    Number of frames in FLI.  FLI files have
                         a maxium length of 4000 frames.
     8    2    width     Screen width (320).
     10   2    height    Screen height (200).
     12   2    depth     Depth of a pixel (8).142flagsMust be 0.
     16   2    speed     Number of video ticks between frames.
     18   4    next      Set to 0.
     22   4    frit      Set to 0.
     26   102  expand    All zeroes -- for future enhancement.

     Next are the frames, each of which has a header:

     byte size name      meaning
     offset
     0    4    size      Bytes in this frame.  Autodesk Animator
                         demands that this be less than 64K.
     4    2    magic     Always hexadecimal F1FA
     6    2    chunks    Number of 'chunks' in frame.
     8    8    expand    Space for future enhancements.  All
                         zeros.

     After the frame header come the chunks that make up the
frame.  First comes a color chunk if the color map has changed
from the last frame.  Then comes a pixel chunk if the pixels have
changed.  If the frame is absolutely identical to the last frame
there will be no chunks at all.

     A chunk itself has a header, followed by the data.  The
chunk header is:

     byte size name meaning
     offset
     0    4    size Bytes in this chunk.
     4    2    type Type of chunk (see below).

     There are currently five types of chunks you'll see in a FLI
file.

     number    name      meaning
     11        FLI_COLOR Compressed color map
     12        FLI_LC    Line compressed -- the most common type
                         of compression for any but the first
                         frame.  Describes the pixel difference
                         from the previous frame.
     13        FLI_BLACK Set whole screen to color 0 (only occurs
                         on the first frame).
     15        FLI_BRUN  Bytewise run-length compression -- first
                         frame only
     16        FLI_COPY  Indicates uncompressed 64000 bytes soon
                         to follow.  For those times when
                         compression just doesn't work!

     The compression schemes are all byte-oriented.  If the
compressed data ends up being an odd length a single pad byte is
inserted so that the FLI_COPY's always start at an even address
for faster DMA.
FLI_COLOR Chunks
     The first word is the number of packets in this chunk. This
is followed directly by the packets.  The first byte of a packet
says how many colors to skip.  The next byte says how many colors
to change.  If this byte is zero it is interpreted to mean 256.
Next follows 3 bytes for each color to change (one each for red,
green and blue).

FLI_LC Chunks
     This is the most common, and alas, most complex chunk.   The
first word (16 bits) is the number of lines starting from the top
of the screen that are the same as the previous frame. (For
example, if there is motion only on the bottom line of screen
you'd have a 199 here.)  The next word is the number of lines
that do change.  Next there is the data for the changing lines
themselves.  Each line is compressed individually; among other
things this makes it much easier to play back the FLI at a
reduced size.

     The first byte of a compressed line is the number of packets
in this line.  If the line is unchanged from the last frame this
is zero.  The format of an individual packet is:

skip_count
size_count
data

     The skip count is a single byte.  If more than 255 pixels
are to be skipped it must be broken into 2 packets. The size
count is also a byte.  If it is positive, that many bytes of data
follow and are to be copied to the screen.  If it's negative a
single byte follows, and is repeated -skip_count times.

     In the worst case a FLI_LC frame can be about 70K.  If it
comes out to be 60000 bytes or more Autodesk Animator decides
compression isn't worthwhile and saves the frame as FLI_COPY.

FLI_BLACK Chunks
     These are very simple.  There is no data associated with
them at all. In fact they are only generated for the first frame
in Autodesk Animator after the user selects NEW under the FLIC
menu.

FLI_BRUN Chunks
     These are much like FLI_LC chunks without the skips.  They
start immediately with the data for the first line, and go line-
by-line from there.  The first byte contains the number of
packets in that line.  The format for a packet is:

size_count
data
     If size_count is positive the data consists of a single byte
which is repeated size_count times. If size_count is negative
there are -size_count bytes of data which are copied to the
screen. In Autodesk Animator if the "compressed" data shows signs
of exceeding 60000 bytes the frame is stored as FLI_COPY instead.

FLI_COPY Chunks
     These are 64000 bytes of data for direct reading onto the
screen.

2 Picture Files (.GIF)

     GIF (Graphics Interchange Format) is a format developed by
CompuServe Information Services.  GIF files are as close to
computer- and resolution-independent as we're likely to see in
the next few years -- there are GIF viewers available for the
Amiga, the Atari ST and 8-bit line, the Tandy Color Computer, the
Apple II, the MacIntosh, Sun workstations, PC compatibles and
most other computers with any sort of graphics display at all.
There are also programs to convert from the more "native" file
formats (such as DEGAS on the ST, IFF on the Amiga, and MacPaint
on the Mac) to GIF.  Many of these conversion programs are
available free on Compuserve.

     GIF files are also fairly densely compressed, using a
modified Lempel-Zif-Welch "ladder" compression scheme similar to
that used in the popular archive programs ARC and PKZIP.

     Unfortunately the nitty-gritty details of what goes into a
GIF file are rather complex, and CompuServe holds the copyright
to much of the documentation.  The PICS forum on CompuServe (type
"go pics" at any exclamation mark prompt) will provide GIF
documentation and much more in the way of useful information to
graphics programmers if you fill out a simple developer's
registration form.  Another place to look for GIF information is
the Autodesk forum on CompuServe; type "go autodesk" to learn
more.

3 Cel Files (.CEL and .PIC)

     A cel file has a 32-byte header followed by the uncompressed
color map (768 bytes) followed by the uncompressed pixel image.

     The header is:
     Byte Offset    Contents
           0        Magic Number - 9119 Hexadecimal
           2        Width of cel
           4        Height of cel
           6        Horizontal screen position of upper left
                    corner
           8        Vertical screen position 10Number of bits in a pixel (8)
           11       Compression type (0 for uncompressed)
           12       Size in bytes of cel image (a 4-byte long
                    word)
           16       16 bytes of zero reserved for future use.

     A .PIC file uses the same format, with width and height
320x200 and screen position 0x0.  (.PIC files are generated in
Autodesk Animator if you supply a .PIC file suffix while loading
or saving a single frame.  Otherwise a GIF file is made.)

4 Palette Files (.COL)

     A color file is just a binary image of the color palette.
It consists of 768 bytes -- three bytes for each color.  Each
byte has a value from 0 to 63.  The red byte comes first, then
the green, then the blue.

5 Mask Files (.MSK)

     A mask file is is an 8000-byte file.  It contains one bit
for each pixel of the screen.  It goes from left to right, top to
bottom.

6 Text Files (.TXT)

   These are just ordinary ASCII files.

7 Font Files (.FNT)

     My font files are a slightly strange hybrid.  They started
out as the same type of file that GEM on the ST uses.  Then some
additions were made to make it easier to convert MacIntosh fonts
to a format Autodesk Animator could use.  My apologies for
creating yet another font file format for the PC (this only makes
about 12 I know of...), especially as I don't completely
understand this one myself!

     A font file starts out with an 88-byte header.  This is
followed by up to three tables of various sizes:
     Byte Offset    Name      Meaning
          0         id        Identifier.  Hex 9000 if
                              Mac-converted
          2         size      Point size of font.  Not used by
                              Animator
          4         facename  32 byte name of font.  Not used by
                              Animator
          36        ADE_lo    Lowest ASCII character in font.
                              More often than not this is 20 hex
                              (space character).
          38        ADE_hi    Highest character in font.
          40        top_dist  unknown, unused by Animator42asc_distunknown, unused by Animator
          44        hlf_dist  unknown, unused by Animator
          46        des_dist  unknown, unused by Animator
          48        bot_dist  unknown, unused by Animator
          50        wchr_wdt  widest character width
          52        wcel_width     widest 'cell' width (includes
                                   distance to next character)
          54        lft_ofst  unknown, unused by Animator
          56        rgt_ofst  if Mac font, is negative of Mac
                              maxKern value.  Else unknown &
                              unused.
          58        thckning  How bold is bold? Unused by
                              Animator
          60        undrline  How far down to underline? Unused
                              by Animator
          62        lghtng_m  Lightening mask. Mask for light
                              style.  Unused by Animator
          64        skewng_m  Skewing mask for italics.  Rotate
                              line on a 1 bit.  Unused by
                              Animator
          66        flags     Will swap bytes of image if bit 2
                              is non-zero.  (Part of DRI's
                              attempt to make 8086/68000 work
                              together.)
          68        hz_ofst   Unknown, unused in Animator
          72        ch_ofst   Unknown, unused in Animator
          76        fnt_dta   Unknown, unused in Animator
          80        frm_wdt   Byte width of bitmap
          82        frm_hgt   Pixel height of bitmap
          84        nxt_fnt   Unknown, unused in Animator

     The first table is a series of 16-bit words containing the
horizontal offset into the font bitmap image of the start of each
letter.  The width of the letter is calculated by subtracting the
offset of the next character from the offset of current
character.  There's one offset for each character in the font,
plus an extra one to give the width of the last character.  This
table is always present.

     The second table contains the font image.  This is a single
bit-map for the whole font (as opposed to a series of bitmaps one
for each character).  This table is always present.

     The third table is only present in fonts we've translated
from the MacIntosh (that is, if the id field in the header is
hexadecimal 9000).  There are two bytes for each character in the
font.  If both bytes are FF hexidecimal it is a 'missing
character', and will not be drawn.  The first byte is added to
the rgt_ofst field of the header to tell how many pixels to move
to the right (or left if the result is negative) before drawing
this character.  The second byte is how many pixels to move to
the right after drawing this character.
8 Polygon and Path files (.PLY)

     A polygon file has an 8-byte header followed by 6 bytes for
each point of the polygon (2 bytes each x,y,z with z always zero
currently).

   Here is the header:
     Byte Offset    Contents
     0              16-bit point count
     2              4 bytes of zero
     6              1 if polygon closed, 0 otherwise
     7              Magic number - hex 99

9 Optics Files (.OPT)

     An optics file has a 4-byte header followed by a series of
optical moves records of 50 bytes each.  Each time you click on
CONTINUE MOVE in the OPTICS menu in Autodesk Animator another
record is generated.  The header format is:
     Byte Offset    Contents
     0              Magic Number - 1A3F Hexadecimal
     2              Number of moves in this file.  16-bit count

   Here's the format for an individual record:
     Byte Offset    Contents
     0              4 bytes of zero (room for pointer to next
                    record when it's loaded into memory)
     4              Spin center.  x/y/z location (16 bits each)
     10             Spin axis.  x/y/z location (16 bits each)
     16             Spin turns  x/y/z (16 bits each)
     22             Intermediate turns.  Two 16-bit words.  These
                    are values for a conjugation matrix that
                    corresponds to spin axis.
     26             Size center x/y/z location (16 bits each)
     32             x multiplier -- together with x divisor
                    determines how to stretch along x
                    (horizontal) dimension
     34             x divisor
     36             y multiplier
     38             y divisor
     40             both multiplier - applied to both x and y
                    dimensions
     42             both divisor
     44             linear move x/y/z offset (16 bits each)

10 Record Files (.REC)

     A record file has a 16-byte header followed by any number of
8-byte input records.  The header format is:
     Byte Offset    Contents
     0              Magic Number - 0713 Hexadecimal2long word (4 byte) count of number of input
                    records
     6              4 bytes of 0
     10             1 if real-time macro, 0 otherwise
     11             5 bytes of 0

   The format of a input record is:
     Byte Offset    Contents
     0              Time (in 70th of second) from last record if
                    real-time, 0 otherwise.
     1              Mouse button state.  Bit 0 is left button,
                    bit 1 is right button.  (i.e. the value is 3
                    if both buttons down, 1 if only left button,
                    0 if no buttons down.)
     2              16-bit keyboard code if key pressed, 0
                    otherwise.
     4              16-bit mouse horizontal position
     6              16-bit mouse vertical position